Automation control systems are well-known. Such systems include building automation systems for controlling environmental equipment, fire and safety equipment, security equipment, elevator banks, and the like. Other automation control systems include industrial control, food processing, and transportation systems. In general, these systems receive data from sensors that are evaluated to determine control actions to take in order to bring about some condition or perform some operation. For example, an environmental control system uses sensors to detect environmental conditions and system parameters throughout a building or other space to determine control actions that are necessary to bring the regulated space to some defined condition.
There exist a wide variety of sensors for a wide variety of purposes. Sensors can include temperature sensors, infrared body detectors, position indicators, water flow meters, air flow meters, water pressure meters, air pressure meters, and the like. Position indicators, for example, are devices that generate a signal that corresponds to the position of a switch, valve, or vent opening so the system controller may determine whether particular lights, fans, vents, or blower motors are operating or open. The data that is generated by the sensors is provided to one or more controllers in the control system.
The controllers in many cases compare the data to desired values for the particular sensed condition. The desired values are called set points. The controllers perform control actions to bring the sensed parameters into compliance with the conditions corresponding to the set points. In some cases, sensors that sense one condition may be used to effect control of another condition. For example, a sensor data that indicates a person's entry into a room may be used to initiate control actions to achieve lighting, ventilation, and thermal comfort conditions specified for an occupied space. Such control actions may include the activation of blower motors to bring conditioned air into the room through vents that are also opened in response to control signals generated by the controller.
Additional control actions may involve obtaining temperature sensor data and controlling the various devices to maintain the desired temperature. In this manner, the controller may regulate the environmental conditions in a space.
Distributed processing may be used in an environmental control system to coordinate control of the system with the various heating, ventilation and air conditioning (HVAC) functions in the system. For example, an air-handling unit (AHU) in an HVAC system distributes conditioned air to several variable air volume (VAV) terminals in a building. Thus, VAV controllers exchange data with the AHU controller so the AHU appropriately provides conditioned air to the VAVs and the AHU controller may synchronize the operation of these local space controllers.
Different companies, however, frequently manufacture the various devices within a control system. Accordingly, it is possible that a device manufactured by a first company would have a communication protocol different from the protocol used by a device manufactured by a second company. When devices of a system employ different protocol, the consumer must absorb the expense of creating an interface system for various devices. Alternatively, the consumer may limit the system to devices from a limited number of manufactures, all of whom employ the same protocol.
In response to this problem, various “standard” communications protocols have evolved which are used by a number of different manufacturers. By ensuring that a replacement device uses the same protocol as the rest of the network, a consumer can purchase a device with the assurance that the device will be able to communicate with the rest of the consumer's system once installed. One such protocol is the LonTalk protocol, also known as the ANSI/EIA 709-1 Control Networking Standard.
The LonTalk protocol is a layered, packet based, peer-to-peer communications protocol designed specifically for control systems. By using devices with a shared protocol, a consumer ensures that a new device, regardless of its manufacturer, will be able to send and receive messages from other devices already in the network. To this end, the protocol ideally enables communication without prior detailed knowledge of the topology of the network. Accordingly, systems using the LonTalk protocol maintain control functions within the various devices while sharing data with other devices in the system. Such a system may be referred to as an information-based control system.
A network based upon the LonTalk protocol allows remote network management tools to interact with components over the network, including reconfiguration of network addresses and parameters, downloading of application programs, reporting of network problems, and start/stop/reset of component application programs. Beneficially, the network may be implemented over basically any medium, including power lines, twisted pair, radio frequency (RF), infrared (IR), coaxial cable and fiber optic or combinations thereof.
Communications protocols such as LonTalk provide significant advantages in implementation of a distributed processing system. However, there are some difficulties associated with such protocols. One such problem arises when devices are replaced with either devices from a different manufacturer or even updated devices from the same manufacturer. Devices that are configured in accordance with the LonTalk protocol are referred to as LonWorks devices. However, a replacement LonWorks device is typically not configured to interface with a system in the same manner as the LonWorks device being replaced.
The primary means of accessing data within a LonWorks device is via Network Variables (NVs) and Configuration Properties (CPs). The NVs are utilized for “dynamic” data within the control application. An example of dynamic data is current zone temperature. The NVs are the primary mechanism by which data is exchanged between control and monitoring nodes on the network. The CPs are utilized for “static” data. Static data is typically stored in a controller's non-volatile memory and can be used to configure the application and/or control parameters within the controller. Static data can be used to configure, for example, input and output configuration and set points. NVs and CPs are identified, among other things, by a name and a type. The “name” identifies the class of sensor, such as a temperature sensor. A data “type” defines the units, scaling and structure of the data being passed. A number of standard NV types (SNVTs) have been created for commonly used types. Collectively, the NVs and CPs within a LonWorks Controller are referred to as the Node Interface. In addition, NVs and CPs within a controller may be organized and/or associated with Objects.
LonWorks devices include “self-documentation” that can be read and interpreted by a LonWorks tool. Recovery and interpretation of the self documentation from a LonWorks node is the primary and most rudimentary mechanism by which a LonWorks tool obtains information on a node's Node Interface. Self-documentation includes a Program Identification (Program ID).
Each Node Interface must be assigned a Program ID. Rules for assigning Program IDs and guidelines for self-documentation are administered by the LonMark Interoperability Association. In accordance with guidelines of the LonMark Interoperability Association, nodes containing the same Program ID must contain the same Node Interface. Thus, it is assumed that LonWorks devices with identical Program IDs have identical NV and CP names, the same number of NVs and CPs, identical organization into Objects, etc. Accordingly, when the self-documentation of a node changes, the Program ID of any device at the node must also be changed.
Typically, but not always, descriptive NV names are included in the self-documentation stored within the LonWorks node. However, such storage obviously requires memory space. Thus, due to memory constraints, some nodes do not include NV names in the self-documentation stored within the nodes. In such cases, LonWorks tools must rely on other means for associating an NV with a descriptive name. The most common, and indeed de facto standard for doing so, is to utilize what is known as an external File (XIF file).
The XIF format is determined and maintained by the LonMark Interoperability Association. The data in the XIF file includes a Program ID and details regarding the functional profile of the device. The XIF file is a text file description of the Node Interface that can be used by tools to have access to an application's Node Interface without the need to retrieve the data from the actual node. The association of the XIF file data with the Node Interface is accomplished via the Program ID.
A Program ID is an identifier for a device that includes a manufacturer identification, a device class, a device subclass and a model number. All devices having the same Program ID will have identical functional profiles. The functional profile is data that defines the application layer interface of the device including NVs, CPs, defaults and power-up behaviors.
Thus, when initially installing a system, a network tool is used to obtain the profiles of the various devices. The network tool is a program loaded into a computer, which may be, for example, a portable computer, a handheld device, or an administrative computer connected to the system. Then, in order to establish the proper recipients and suppliers of messages in a LonWorks system, a process referred to as “binding” is performed during network setup. The binding process establishes the logical connection between the devices by connecting the NV Objects (NVOs) from one node or nodes to the NVOs of the same type on other node or nodes. From a network perspective, the devices can thus be thought of as nodes having specific configurations. The logical connections are then stored within the configuration file used by the system.
When a replacement device is connected to the system, logical connections with the replacement device must be established. If the replacement device is identical to the previous component, i.e. the same Program ID, establishing the logical connections may be fairly simple. Some network management tools have the capability of verifying the Program ID, and merely re-establishing the logical connections already defined for all of the nodes that are members of the respective connection.
However, in the event the replacement component has a different Program ID, such as may occur when adding functionality, switching manufacturers, or providing an entirely new functionality, prior art network management tools assume the node to be different, and do not automatically attempt to establish the logical connections to the device. Moreover, if the original network management database is not available and a network image cannot be recovered by the network management tool, then the node must be manually configured. A typical controller may have sixty NVs and up to one hundred CPs. Obviously, manually configuring the node is labor intensive in engineering and testing and prone to error. The problems are exacerbated if more than one component is replaced at the same time.
What is needed is a network tool capable of automatically re-establishing NV connections and CPs even when a device is replaced with a node having a different Program ID. It would be beneficial if the network tool were capable of identifying conflicts or changes in node configuration, allowing a user to quickly assess the conflicts or changes. It would be further beneficial if the network tool provided potential conflict resolution options.